Policy Studio

This feature allows adding to route requests information that is not contained in the route requests but which is taken from the Users page. To accomplish this with legacy products without ARM, the LDAP server must be queried for every call using complex query rules, creating delays and straining the server. In the ARM, the Users page is loaded to memory and information gathering is handled internally in real time. Policy Studio Use Examples:

■ Each user has an internal 4-digit extension and an unrelated external phone number. When a user makes a call outside the enterprise, the source number, i.e., the user's extension, must be replaced with their external number. When a call comes in from outside, the external number must be replaced with the user’s extension.
■ Same as the previous example but, in addition, there can be more than one user with the same extension, and what differentiates them is their hostname. The ARM can locate the user based on a combination of the extension and hostname attributes.

Policy Studio is a set of rules. Each rule contains a match condition and an action. The match condition is a set of route request fields to be compared, and a set of user properties to be compared to. The match condition also has a source node or Peer Connection or set of source nodes or Peer Connections. The action is a set of route request or response fields to be replaced, and a set of user fields to replace them with. For every route request received, the ARM processes all the rules from top to bottom. For each, the ARM searches in the users table for a user that matches all the fields. If a user is not found, the ARM proceeds to the next rule. If a user is found, the ARM stops parsing the rules and performs the action in this rule. The action is to replace all the listed fields with the properties of the user, as configured.

➢ To add a Policy Studio rule:
1. Open the Policy Studio page (Settings > Call Flow Configurations > Policy Studio).

2. Click the add icon + and from the 'Type' drop-down, select User, Web Service, Credentials, Blacklist or DIDs Count:

Web Service

Credentials

Black List

DIDs Count

3. Configure the settings using the following table as reference.

Policy Studio Settings

Setting Description

Name

Defines the name of the Policy Studio rule to add, to facilitate management of the feature.

Type

Policy Studio supports five rule types, as shown in the preceding figures:

■ User (default). Select this to use Policy Studio based on information taken from ARM Users Data.
■ Web Service. Select this to use an external web service for pre-routing manipulation. See also Web-based Services.
■ Credentials. Select this for the SBC to function as authentication server for SIP messages requests and for the ARM to centrally manage the user credentials of all SIP phones in the global network. See Adding a Policy Studio Rule for Users Credentials Information for more information.
■ Blacklist. Select this to add into a blacklist a phone number of a caller/ callee if it is called more than a defined number of times within a defined time period. See Managing a Dynamic Blacklist for more information.
■ DIDs Count. Select this to indicate a phone number of a caller/ callee if it is called more than a defined number of times. See Configuring DIDs Count for more information.

MATCH

The set of match conditions for finding a user from the Users table. Click + to add more conditions.

Source Nodes

From the drop-down, select a Node or set of Nodes for which this rule will be used. Alternatively, click the adjacent button to select a Node or set of Nodes from the Topology Map. If left empty, the rule is used regardless of the origin of the call.

Note: To select multiple elements in the Choose Topology Item screen, press Ctrl and click the elements.

Source Peer Connections

Select a Peer Connection or set of Peer Connections for which this rule will be used. Alternatively, click the adjacent button to select a Peer Connection or set of Peer Connections from the Topology Map.

If left empty, the rule is used regardless of the origin of the call.

Note: To select multiple elements in the Choose Topology Item screen, press Ctrl and click the elements.

Source Resource Groups

Select a set of Nodes or a set of Peer Connections for which this rule will be used. If left empty, the rule is used regardless of the origin of the call.

Source Prefix / Prefix Groups

Allows a Prefix or a Prefix Group to be configured as the ‘Source’ in a Policy Studio condition. Optionally add the condition for users’ information-based pre-routing.

Destination Prefix / Prefix Groups

Allows a Prefix or a Prefix Group to be configured as the ‘Destination’ in a Policy Studio condition. Optionally add the condition for users’ information-based pre-routing.

Destination is a registered user in ARM

If this option is selected, the Policy Studio rule will be matched only if the destination number is a registered user's number (listed in the Registered Users table).

Request type

This condition in a Policy Studio rule of type ‘User’ allows differentiation between a Policy Studio rule to be used for call setup and a Policy Studio rule to be used for routing registration messages.

Default: Call.

Switch the 'Request type' to Register if you want to use the Policy Studio rule for registration messages manipulations / prerouting manipulation.

The following example applies pre-routing tagging to all registration messages based on value Country of the Users table, which can later be used for Tag-based routing. For example, route users registration to different SoftSwitches based on the value of Country.

SIP Header

Select a route REQUEST field from the following available fields (this is a field from the route REQUEST that is compared with the user properties):

■ SOURCE_URI_USER (default)
■ SOURCE_URI_HOST
■ DEST_URI_USER
■ DEST_URI_HOST
■ CONTACT_URI_USER
■ CONTACT_URI_HOST
■ CONTACT_URI_PORT
■ P_ASSERTED_IDENTITY_DISPLAY_NAME
■ P_ASSERTED_IDENTITY_USER
■ P_ASSERTED_IDENTITY_HOST

If a call matches the selected criterion, the manipulative action you select will be performed. For a SIP field manipulation example, see Example 2 under Example 2 of a Policy Studio Rule.

Site

Allows configuring a ‘Site’ condition as a matching criterion. This is necessary for DID masking in the case of an E911 (Teams emergency call and call-back). See also DID Masking. The matching criterion is needed to provide a separate range of DID numbers for Teams emergency calls on a per-site basis.

Teams uses a proprietary LMO (Local Media Optimization) header to indicate the user’s current site: X-MS-UserSite, shown in the next figure. See also Configuring a Microsoft Teams LMO Topology.

A DID masking Policy Studio rule matching this attribute enables you to manage emergency numbers with a separate pool of numbers for each site (coordinated with Teams definitions). In the example shown in the preceding figure, the SIP field X-MS-UserSite is set to Boston; emergency calls with a call-back Policy Studio rule will consequently only be applied to calls from the ‘Boston’ site. Note that this field allows multiple values to be set; the same rule will then be applied to multiple sites.

ACTION

The set of replacement actions that will be performed on the route request and route response fields for a found user.

Action field

Select a route request or route response field from the following available fields (when a user is found, this field will be replaced with the value of the configured user properties):

■ SOURCE_URI_USER
■ SOURCE_URI_HOST
■ DEST_URI_USER
■ DEST_URI_HOST
■ DEST_IP_ADDR
■ DEST_PORT
■ DEST_PROTOCOL
■ USER_CREDENTIALS_USER_NAME
■ USER_CREDENTIALS_PASSWORD
■ P_ASSERTED_IDENTITY_DISPLAY_NAME
■ P_ASSERTED_IDENTITY_USER
■ P_ASSERTED_IDENTITY_HOST
■ TAG_1 (see here for more information)
■ TAG_2 (see here for more information)
■ TAG_3 (see here for more information)
■ INCOMING_CUSTOMER_TAG
■ OUTGOING_CUSTOMER_TAG
■ X_ARM_INFO_1
■ X_ARM_INFO_2
■ X_ARM_INFO_3

Multiple actions can be defined. Click + to define another action.

Note: If either USER_CREDENTIALS_USER_NAME or USER_CREDENTIALS_PASSWORD is used in an action, you must add both.

For a SIP field manipulation example, see Example 2 under Example 2 of a Policy Studio Rule.

Source or Destination Number

[Applies to a Policy Studio Rule whose 'Type' is Black List or DIDs Count].

Select Source Number for the caller’s phone number or Destination Number for the callee’s phone number.

See Managing a Dynamic Blacklist.

See Configuring DIDs Count.

Conditions

 

 

[Applies to a Policy Studio Rule whose 'Type' is Black List].

Call time range (seconds). Default: 60.

Number of calls during time range criteria. Default: 5.

See Managing a Dynamic Blacklist.

 

[Applies to a Policy Studio Rule whose 'Type' is DIDs Count]

Number of calls from first hit. Default: 5

See Configuring DIDs Count.

Action

[Applies to a Policy Studio Rule whose 'Type' is Black List].

Blocking number time period (minutes). Default: 60 minutes.

See Managing a Dynamic Blacklist.

 

[Applies to a Policy Studio Rule whose 'Type' is DIDs Count]

■ Select the Clear DID count timer from the first hit option and then configure the Block Number Duration (in minutes). Default: 60.
■ Select the Clear DID count at option to clear the counting every day at a specific time.

See Configuring DIDs Count.

Match

[Applies to a Policy Studio Rule whose 'Type' is Black List or DIDs Count]. From the drop-down, select a tag:

■ TAG_1
■ TAG_2
■ TAG_3

See here for more information.

Click the drop-down arrow on the right:

Select the option you require and then click Apply.

White List

[Applies to a Policy Studio Rule whose 'Type' is Black List]. Click the drop-down arrow and select a list of numbers that will never be blocked.

Generate alarm when number is blocked

[Applies to a Policy Studio Rule whose 'Type' is Black List]. Select this option for an alarm to be generated when a number is blocked. See also Active Alarms | History Alarms.

Request User Property

Select a set of user properties. The request field is compared to these properties of the users. If any of the properties of a user is equal to the value of the field, then this condition is considered a match.

Replacement User Property

Select a set of user properties. The action is to replace the value in the request or response field with the value of this user property. If the found user has no value for this property, then no action is done on this field. If there more than one property is listed here, then ARM replaces the field with the first property if the user has it. If the user does not have it, ARM proceeds to the next property in the list, in the configured order.

Flow

Allows operators to exercise an option to control the action to be executed after a Policy Studio rule is matched. Use the following as reference when configuring ‘Flow’:

■ Stop. This is the default action. When the rule is matched, the ARM stops and continues to Routing Rule matching.
■ Continue. The ARM continues to the next matching Policy Studio rule.
■ Continue to policy studio rule. The ARM continues to the next matching Policy Studio rule from a specific Policy Studio rule. This essentially triggers execution of the rule.

Fields such as ‘Source Nodes’ and ‘Source Peer Connections’ in Policy Studio’s Add Call Item screen and Edit Call Item screen feature filters in which network administrators can select multiple elements and then invert the selection. The feature improves usability and user experience especially in large networks with high numbers of elements. The feature allows network administrators to

● Select a single element
● Delete a single element (x)
● Select All elements
● Clear all selected elements
● Select All and delete a few (x)
● Select All, delete a few (x) and then invert the selection; the elements deleted will be in the selection
● Select a few elements and then invert the selection; only elements that weren’t selected will be in the selection
● Clear a selection